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W A method for network selection in communication 
networks, related network and computer program product 
therefor" 

* * * 

5 Field of the Invention 

— — — — _ — i 

The invention relates to network selection 
procedures for communication networks, e.g. IP networks 
such as wired and wireless local area networks (LANs) . 
More specifically, the invention relates to 
10 arrangements wherein a plurality of network operators 
share an IP network. 

Description of the Related Art 

The possibility for several network operators and 
internet service providers (ISPs) of being jointly 
15 present in a IP network, such as a wireless LAN (WLAN) 
and supporting roaming is a key requirement for the 
deployment of a Public WLAN, as described e.g. in 3GPP 
TR 22.934 v 6.1.0 feasibility study on 3GPP system to 
Wireless Local Area Network (WLAN) interworking 
20 (Release 6)", December 2002. The capability of 
permitting roaming and allowing a user to choose an 
appropriate network is also requested by several 
national regulatory bodies. 

Currently available access procedures to data 
25 networks of service providers have only a very limited 
flexibility. In fact, the provider of the access 
network has usually contracted trades with other 
internet providers . The customers of these providers 
can access the respective networks through the network 
30 access facilities of the provider of the access 
network. Typically, the operator providing access to 
the network will in turn have agreements also with 
other providers or operators; in many cases, however, 
the operator providing access to the network to a 
35 certain user has not a direct roaming agreement with 
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the home operator of that user, but only with one or 
more third operators that in turn may have agreements 
with the user's home operator. 

The customers of these providers or operators will 
5 not generally be aware of these agreements. Finding 
themselves in the coverage area of a given wireless 
internet service provider (WISP) they will not have the 
possibility of knowing where the authentication 
information will be sent and therefore what transport 
10 networks will carry their data. 

A corresponding roaming scenario is represented in 
Figure 1. There, two users A and B are shown. These 
users are subscribers to services provided by two 
respective home service providers, namely HSPA and 
15 HSPB. Both of A and B want to access the services of 
their HSPs from a generic access service provider ASP 
through its access network AN. The provider ASP could 
have a direct roaming agreement with certain visited 
service providers, such as e.g. VSP1 and VSP2 . These, 
20 in turn, may both have a roaming agreement with HSPA. 
These latter agreements may however differ, e.g. in 
terms of pricing and quality of service (QoS) granted. 
The access provider ASP could also have a direct 
roaming agreement with another visited service provider 
25 VSP3 having in turn a roaming agreement with HSPB. 
Finally the access provider ASP might also have a 
direct agreement with another "home" service provider 
of a user C, namely HSPC. 

During authentication of clients requesting access 
30 to the access network AN, the access service provider 
ASP will send an authentication request to one of the 
service providers directly connected thereto, namely 
VSP1, VSP2, VSP3 or HSPC. In fact the access service 
provider ASP is not in a position to authenticate users 
35 A and B locally. In current arrangements, the access 
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service provider ASP will take the corresponding 
decisions in an autonomous way, without receiving from 
the users A or B any input data other than their 
identity. Such a situation may explain why network 
5 advertising, i.e. the announcement of network operators 
available in a given public WLAN and the need for 
network selection are described in documents such as 
3GPP S2 -031899 U WLAN Network selection", San Diego 
Meeting, 12-16 May 2003 

10 (www. 3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_32_San_Diego/td 
ocs) , while indicating that the mechanism for network 
advertising is still "to be discussed" . 

An alternative arrangement based on XML meta- 
language has been proposed by document 3GPP S2- 03 18 64 

15 "Network Selection", San Diego Meeting, 12 - 16 May 
2003 (www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_32_San_Dieg 
o/tdocs) . The corresponding arrangement has the 
disadvantage of requiring XML pre -configuration. 
Furthermore, the XML code has an increased amount of 

20 tagging information, which requires a greater amount of 
bits to be transmitted. 

Object and summary of the invention 

The object of the present invention" is thus to 
provide an arrangement that overcomes the drawbacks of 
25 the prior art arrangements as outlined in the 
foregoing. 

According to the present invention, that object is 
achieved by means of a method having the features set 
forth in the claims that follow. 

30 The present invention also relates to a 

corresponding communication network and a computer 
program product loadable in the memory of at least one 
computer and including software code portions for 
performing the method of the invention. Reference to at 

35 least one computer is evidently intended to take into 
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account that the method of the invention is adapted to 
be carried out in a decentralised manner, with 
different tasks being allotted to different computers 
in a network, 

5 In brief, an arrangement is described where a user 

wishing to access - via a third-pajrty access network - 
the network of one of his providers, is enabled to 
choose the intermediate network (s) to which i.a. the 
authentication information shall be passed. 
10 In that way, the user will also be able to select 

the path his or her data will follow, in the case that 
his provider has a number of roaming agreements with 
other providers that, in turn, have agreements with the 
provider acting as the access provider. 
15 . This arrangement is independent from of the access 
technology deployed within the access network. This can 
be either wireless (e.g. a WLAN network) or wired (e.g. 
a PSTN network with dial-up access) . For the sake of 
simplicity, a wireless LAN will be steadily referred to 
20 in the following as a preferred example. 

The provider acting as the access service provider 
is in charge of communicating the possible alternatives 
to the users, thus enabling them to make their choices. 
The arrangement described herein solves i.a. the 
25 problem of network advertising as presented in the 
document 3 GPP SA2 -031899 already mentioned in the 
foregoing . 

A preferred embodiment of the arrangement described 
herein is based on the so-called Diameter agent 

30 supported in a Diameter base protocol. The basic 
related information is provided e.g. in IETF draft- 
ietf -aaa-diameter-17 .txt "Diameter Base Protocol", 
www. ietf .org . The Diameter agent is used to provide an 
authentication, authorization and accounting (AAA) 

35 framework for applications such as network access or IP 
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mobility. Essentially, a Diameter agent is a Diameter 
node that provides either relay, proxy, redirect or 
translation services. Specifically, the arrangement 
described herein provides for certain modifications 
5 being made in the way specific Diameter requests are 
processed and the relative answers are created by the 
Diameter agent when these authentication requests have 
an unknown realm. 

Currently, these requests would be discarded or, in 
10 the best case, would be forwarded towards a default 
authentication server. With the proposed modifications 
a Diameter agent can retrieve the information necessary 
to correctly process the authentication request thus 
giving the user the possibility of choosing the visited 
15 authentication server to which the Diameter agent must 
forward the request . 

Those of skill in the art will appreciate that the 
same arrangement could also be used with other 11 triple - 
A" protocols such as e.g. the protocol currently 
20 referred to as Remote Authentication Dial- In User 
Service (RADIUS) : this does not provide for explicit 
support for agents, including ' so-called proxies, 
redirects and relays. The expected behaviour will not 
be defined, as this may vary for different 
25 implementations . 

The list of supported visited networks having a 
roaming agreement with a certain user's "home" ISPs are 
sent to the user by the authentication server of the 
provider acting as the access provider. This preferably 
30 occurs during the user authentication procedure, using 
an extensible authentication protocol (EAP) . This 
authentication protocol (as described e.g. in IETF 
draf t-ietf -eap-rf c2284bis-03 . txt , www. ietf .org ) 

supports multiple authentication mechanisms and 
35 typically runs directly over the link. 



WO 2005/002140 



PCT7IT2003/000409 



6 

For this purpose, a modification to the EAP 
procedure is advisable that consists in adding two 
messages to the normal sequence of packets exchanged 
during the authentication. However, the method proposed 
5 should be supported by a generic authentication 
mechanism indipendently of the underlying WLAN 
standard. 

The main advantage of the arrangement in question 
lies in that no need exists of modifying the local 
10 access device, since any modification can be 
implemented at the client terminal and in the AAA 
servers . 

In a presently preferred embodiment of the 
invention, the user is identified ' univocally by means 
15 of an identifier. 

This may be e.g. the network access identifier 
known as NAI described e.g. in RFC 2486 3GPP S2- 031864 
"Network selection", San Diego Meeting, 12-16 May 2003 
(www . 3gpp . org/f tp/tsg_sa/WG2_Arch/TSGS2_32 JSanJDiego/td 
20 ocs) . 

In such a preferred embodiment, the user sends his 
or her credentials to the access network (which may 
occur by means of either a wired device or a wireless 
device) . The access network forwards these credentials 

25 to a back-end authentication server, located at the 
data center of the access service provider. The 
authentication server retrieves the available roaming 
networks for that user, identified through the realm 
part of the NAI. To accomplish this task, the server 

30 initiates a conversation with the servers belonging to 
the providers to which it is connected. As a result, 
the authentication server retrieves the list of 
operators that hold a roaming agreement with the user's 
operator (s) . This procedure is performed only once when 

35 a first authentication request is received by the 
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authentication server in respect of a user for which no 
direct roaming agreements exist with the home server 
provider of such a user. The authentication server also 
forwards, via the access network, a list of operators 
5 to the user. The user chooses one of the operators from 
the list received from the server, according to his or 
her preferences, or based on some pre -configured 
settings. When presented with such a list, the user 
will send the chosen operator identifier back to the 
10 authentication server in the access network and the 
authentication server will forward to the provider 
chosen by the user the authentication request, 
containing the user's credentials. 

Of course, in the case the provider acting as the 
15 access provider has a direct roaming agreement with the 
user's home service provider, the user will be 
presented with a list comprised of one operator only. 
Alternatively, under these circumstances, the 
authentication server may simply decide to directly 
20 forward the authentication request to the user' s home 
service provider. 

The user will then perform a usual authentication 
procedure with his service provider (for example, using 
a standard mechanism like EAP) . While performing the 
25 steps of this procedure, the authentication information 
flows through the network of the previously chosen 
operator. Specifically, the authentication server will 
forward authentication messages to the visited 
authentication server. These will in turn proxy such 
30 messages to the home operator server, i.e. the home 
authentication server. Being given the possibility of 
choosing the provider to which the access service 
provider will forward the authentication request, the 
users will in fact route their data flows with the 
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ensuing possibility of making choices e.g. in terms of 
pricing and quality of service (QoS) granted. 
Brief description of the drawings 

The invention will now be described, by way of 
5 example only, by referring to the enclosed figures of 
drawing , wherein : 

- figure 1, per se related both to the prior art 
and to the invention, has been already described in the 
foregoing, 

10 - figure 2 is a diagram illustrative of a 

simplified interworking model, 

- figure 3 is a diagram illustrative of a specific 
roaming scenario 

figure 4 is a functional block diagram 
15 schematically representing a generalised network 
selection procedure, 

- figure 5 is a detailed diagram of a network 
selection procedure in WLAN interworking, 

- figure 6 is a diagram illustrative of network 
20 selection in web based access, and 

figure 7 is another functional block diagram 
schematically representing a network selection 
procedure . 

Detailed description of preferred embodiments of 
25 the invent ion 

The exemplary detailed description provided herein 
refers to a network selection procedure applied to a 
public land mobile network (PLMN) . Specifically a user 
equipment accessing a 3 GPP system over a WLAN will be 
30 considered as an example. 

In general terms, the procedure follows the 
network selection principles described in the document 
3GPP TS 23.234 "3 GPP system to Wireless Local Area 
Network (WLAN) Interworking; System Description 
35 (Release 6) " . 
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Radio access network sharing or provider selection 
is used for network selection in 3GPP-WLAN 
interworking . In figure 2 a simplified interworking 
model is presented where all the players are shown i.e. 
5 a WLAN internet service provider WLAN ISP, a visited 3G 
operator VSP, and a home 3G operator HSP. 

It will be assumed that a 3G subscriber wishes to 
utilise the resources and access to services within the 
respective own 3GPP operator network. 
10 The goal of 3G-WLAN interworking is to extend 3GPP 

services and functionality to the WLAN access 
environment. Thus the WLAN effectively becomes a 
complementary radio access technology to the 3GPP 
system. 3G-WLAN interworking shall be independent of 
15 the underlying WLAN radio technology. 

The WLAN provides access to services that can be 
located either in the WLAN itself or in a network that 
is connected to the WLAN. However, it may be reasonably 
assumed that the WLAN will not have roaming agreements 
20 with all 3G operators. Usually the WLAN operator (or 
the WLAN service provider) will be in technological 
partnership with a limited number of 3G operators (i.e. 
the "visited" operators VSP) to provide ^connectivity 
towards other 3G networks (including the "home' 7 network 
25 provider from the user's viewpoint); 

Specifically, a scenario of the kind illustrated in 
figure 3 will be considered. 

There, an area is shown covered by a set of 
overlapping WLAN internet service providers (WISP) 
30 designated WISP 1, WISP2, and WISP3, respectively. Each 
of the providers WISP 1, WISP2, and WISP3 is possibly 
distinguished by different WLAN channels and different 
(and not exclusive) roaming agreements with several 3G 
operators 3G1, 3G2 , 3G3 . 
35 A generic user entering this area may desire to 
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connect to his or her own specific u home" network 3GA, 
3GB, or 3GC to which he or she is a subscriber. This in 
order to be authenticated and to access services 
located either in the WLAN itself or in a network 

5 connected to the WLAN and having a specific agreement 
with the home 3G operator. 

The arrangement described is intended to give the 
user the possibility of selecting a signalling path to 
obtain authentication and authorization from the home 

10 network. Any subsequent user data flow will in fact be 
highly likely to follow the same path used for 
signalling. The possibility thus exist for the user of 
making choices between different commercial agreements 
e.g. in terms of pricing and quality of service (QoS) 

15 granted. 

Referring to figure 3, the user subscribing to the 
services provided to the 3G operator 3GA can reach the 
associated home network in two different ways, e.g. via 
either of visited operators 3G1 and 3G2 . 

20 The prior art fails to provide any specific 

mechanism for making a choice between the two. 

This applies, e.g. to the IEEE 802.11 standard, but 
similar remarks apply to other WIiAN technologies. In 
fact, in the case of IEEE 802.11 WLANs, the WLAN 

25 network name is conveyed over the WLAN beacon signal in 
the so-called SSID (Service Set ID) information 
element. The possibility also exists for a user 
equipment (UE) to actively solicit support for 
specific SSIDs by sending a probe request message and 

30 by receiving a reply if the access point does support 
the solicited SSIDas defined by IEEE 802.11. However, 
in such prior art arrangements the user will not become 
aware of the set of supported visited networks and thus 
possbily select the path for reaching the desired home 

35 operator by using this' mechanism. 
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The arrangement described herein suggests a 
mechanism for the WISP authentication server to send to 
the user a list of the supported visited networks that 
have a roaming agreement with the user's home internet 
5 service provider. 

This happens during the user's authentication 
procedure, that is, when an user sends out his or her 
credentials . 

In the case of WLAN-3G system interworking, support 
10 in that respect can be provided by a generic 
authentication mechanism (indipendently of the 
underlying WLAN standard) , such as e.g. the extensible 
authentication protocol currently referred to as EAP. 
In the case of 3G users the authentication mechanism to 
15 be transported may thus be based e.g. on the existing 
EAP/AKA authentication mechanism described in the 
Internet Draft "draf t-arkko-pppext-eap-aka-09 . txt , "EAP 
AKA Authentication" , February 2003, www, ietf .org/ internet- 
drafts / draft - arkko -pppext -eap z aka- 0 9 . An altemat i ve may be 
20 represented by the EAP/SIM authentication mechanism 
described in the Internet Draft Mraf t -haver inen- 
pppext-eap-sim-10.txt", U EAP SIM Authentication w , 
February 2 0 0 3 , www, ietf .org/ internet -draf ts /draft -haver inen- 
pppext - eap - s im- 1 0 txt . 
25 The corresponding access authentication server 

(AauS) will be assumed to reside in the WISP (i.e. any 
of the elements indicated as WISP1, WISP2 and WISP3 
in figure 3) . This is typically a Diameter node with 
the function of Diameter proxy/relay (DRL) Agent. 
30 The visited authentication server (VauS) will be 

assumed to reside in the visited 3G Operator (i.e. any 
of 3G1, 3G2 or 3G3 in figure 3) and is a Diameter node 
that acts as a Diameter relay/proxy agent (DRL) and 
also as a Diameter redirect agent (DRD) . A Diameter 
35 implementation may act as one type of agent for some 
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requests, and as another type of agent for others . A 
Diameter agent is thus present in the VauS in order to 
act as : 

- a proxy/relay agent for those requests that must 
5 be forwarded towards a visited authentication server 

(VauS) identified at the AauS, and 

- as a redirect agent for those authentication 
requests that have an unknown realm. 

The diagram of figure 5 details the procedure 
10 described in the following. 

As a first step, the access network device sends an 
EAP-request/identity message to the user equipment (UE) 
for user's credentials. EAP packets are transported 
over the wireless LAN interface encapsulated within any 
15 wireless LAN tecnology specific protocol. 

As a second step, the UE sends the user identity in 
an EAP -response/ identity message to the access network 
device complying with a network access identifier (NAI) 
format as specified in RFC2486. The NAI contains the 
20 identifier that allows the AauS to derive the 3G home 
network name. For instance the UE may send the User A 
identity as username@HSPA . com or, for those customers 
that use a SIM module as the identification means, as 
IMSI@HSPA.com . 

25 As a third step, the access network device forwards 

the client's EAP-response packet to its relay DRL AauS. 
Typically, this is encapsulated in a Diameter packet 
with the clients identity in the Diameter User Name 
attribute. 

30 As indicated, in the exemplary embodiment 

considered herein the AauS is a Diameter proxy/relay 
(DRL) agent adapted to look for the realm in the 
Diameter-EAP request message. In fact, this would not 
generally have a routing entry in its Diameter routing 
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table for HSP A. com: this is because direct roaming 
agreements exist only for only with VauS 1, VauS 2, 
VauS 3 and the home service provider HSPC. 

The routing table, which typically is realm-based 
5 is configured in such a way that all the authentication 
requests whose realm does not correspond to any of 
those present in the routing table are redirected to 
all the VauS/DRDs. The AauS thus sends a redirect 
request to all VauS/DRDs and places the user's request 
10 in a pending state. This is essentially a fourth step 
in the process considered. 

As a subsequent, fifth step, all the VauS/DRDs act 
in this case as redirect agents returning a redirect 
notification to the AauS/DRL, with the information 
15 necessary to reach the home authentication server. The 
. relative information is inserted in one or more 
instances of redirect host AVP (Attribute Value Pair) 
in the answer message . 

Essentially the following events occur in the 
20 exemplary scenario just described. 

The VauSl (DRD) has a roaming agreement with the 
home service provider HSP A: consequently, it returns 
to the AauS a redirect notification by setting 
Redirect-Host AVP=VauS 1. In this way the . AauS knows 
25 that the VauS 1 is able to forward the authentication 
request to the home service provider HSPA. The value 
VauS 1 in the AVP is then used by the AauS to form the 
PLMN list that is presented to the user to permit 
selection of the preferred operator. 

30 Also the VauS 2 (DRD) has a roaming agreement with 

the home service provider HSP A: consequently, it 
returns to the AauS a redirect notification by setting 
Redirect-Host AVP=VauS 2. In this way the AauS knows 
that the VauS 2 is able to forward the authentication 
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request to the home service provider HSPA. The value 
VauS 2 in the AVP is then used by the AauS to form the 
PLMN list that is presented to the user to permit 
selection of the preferred operator. 

5 The VauS 3 (DRD) does not have a roaming agreement 

with the home service provider HSPA but does have one 
such agreement with the home service provider HSPB, so 
it must return a redirect notification with Redirect- 
Host AVP= Unknown. In this way the AauS knows that the 

10 VauS 3 will not be able to forward the authentication 
request to the home service provider HSPA) . The value 
Unknown in the AVP is used in order to indicate to the 
AauS not to insert the VauS 3 in the PLMN list. 

Other information can be included in the redirect 
15 notification such as the AVPs listed in the following. 

- Redirect -Host -Usage AVP: this AVP dictates how 
the routing entry from the redirect -host is to be used 
by the AauS/DRL. When set to ALL-REALM, all the 
messages destined for the realm requested are sent to 

20 the host specified in the redirect -host AVP. In the 
example described herein, all authentication requests 
with realm HSPA may be sent by the AauS/DRL to the VauS 
1 or VauS 2 . 

- Redirect -Max- Cache -Time AVP: this AVP contains 
25 the maximum number of seconds the route table entry, 

created as a result of the Redirect -Host , will be 
cached. This AVP avoids that the AauS may have to 
interrogate all the VauS/DRDs if it receives again an 
authentication request for some unknown realm. For 

30 example, in the example described herein, the AauS can 
receive at the same time more than one authentication 
request with realm "HSPA.com". In this way, it already 
has an available VauS/PLMN list to send to the users. 
When the timer expires the AauS repeats, if necessary, 

35 the redirection process thus updating the routing 
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entries regarding the roaming agreements. The AauS can 

send an unsolicited redirect message to all the 
VauS/DRDs for a given realm. The VauS can answer with 

an unsolicited redirect response message. An 

5 alternative is for the AauS to wait for a new 

authentication request for the particular realm and 
repeat the redirection process only at this time. 

When the AauS has received redirect notifications 
from all VauS (DRD) it is in a condition to add a 

10 routing entry in the realm-based table for the 
particular realm. In the example described herein, 
after the redirection procedure, in the AauS routing 
table there will be an entry for the HSPA realm based 
on which the authentication requests can be forwarded 

15 to VauS 1 or to VauS 2. 

As shown in figure 6, if the AauS receives all the 
redirect notifications with the redirect host AVP = 
unknown, then it forwards the authentication request, 
as received in the third step above, to the Vaus 
20 spedified in the default entry of its routing table. 
This operation will be carried out only after the 
reception of the unsuccessful notifications. 

For the authentication of other HSPA users, the 
AauS has already an entry, so that no redirection 

25 procedure is necessary: in such a case the AauS 
searches the routing table, finds the entry already 
present and, after completing the third step considered 
in the foregoing, directly proceeds to either ' of the 
sixth step described in the foregoing or to a variant 

30 thereof . 

The variant in question refers to the case where 
only one VauS is able to forward the authentication 
request to the HSP concerned, that is, there is only 
one VauS that has a roaming agreement with such an HSP. 
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In the example described herein, when the user B 
sends his authentication request (this is essentially 
the third step considered in the foregoing) , the AauS 
does not have a routing entry for the HSPB realm. 

5 Therefore it uses a redirection procedure to retrieve 
the necessary information. In that case, the AauS 
receives only one redirection message with a valid 
redirect -host AVP. This message comes from VauS 3, the 
only one having a roaming agreement with the provider 

10 HSPB. 

The possibility of choosing a preferred operator 
(PLMN) will not exist for the user B; as a consequence, 
the AauS can directly forward the user's credential to 
VauS 3, as soon as the redirect notification message is 
15 received. For this purpose the AauS uses the u Hop-by- 
Hop" field in the Diameter header' to find the user's 
authentication request in the pending state that must 
be forwarded. 

If, conversely, the possibility of choosing between 
20 several VauS/PLMNs exists for the user in question 
(that is, there exist more than one VauS having a 
roaming agreement with the desired HSP) , _the AauS is 
not required to select one of them as the destination 
of the redirected message, but will simply give the 
25 user the possibility of choosing it in the way detailed 
in the following. The AauS will support a Diameter EAP 
application, in order to be able to send the VauS list 
(PLMN list) to the user through an EAP packet 
encapsulated in a Diameter message. The Hop-by-Hop 
30 field in the Diameter header of the authentication 
request in the pending state is used by the AauS to 
send a Diameter/EAP-request message, with an EAP packet 
encapsulated therein. 

This EAP packet includes the VauS/PLMN list. The 
35 user chooses the preferred PLMN/VauS operator and 
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sends this choice to the AauS in a Diameter-EAP- 
response message. Based on the user's selected realm in 
the EAP packet, the AauS forwards the authentication 
Pending Diameter-EAP-request/identity message to the 
5 VauS selected by the user. 

A specific EAP type must be defined in order to 
transport the VauS/PLMN list towards the user. In 
figure 5 this EAP type is indicated wit xxx. 

In the example described herein, the user A 
10 receives the VauS/PLMN list from the AauS with the 
possibility of choosing VauS 1 or VauS 2 (these 
operations essentially comprising the sixth and seventh 
steps in the procedure) . The User A selects VauS 1 as 
the prefered PLMN and sends this choice to the AauS, 
15 these operations essentially comprising an eighth and a 
ninth steps in the procedure. Finally, the AauS 
forwards the pending Diameter-EAP request/ identity to 
VauSl that in turn forwards (in what is essentially a 
tenth step in the procedure) the request to the 
20 provider HSPA for authentication. 

An arrangement has thus been described where the 
identifiers of the networks available within a WLAN are 
transmitted to the user. The authentication server 
retrieves the available roaming networks for that user, 
25 identified through e.g. the realm part of the network 
access identifier (NAI) . To accomplish this task, the 
server initiates a conversation with all the servers 
belonging to the providers to which it is connected. As 
a result, the authentication server retrieves the list 
30 of the operators having a roaming agreement with the 
user's home operator. This procedure is performed only 
once, that is at the first authentication request 
received by the authentication server for a user for 
which it does not have a directed roaming agreement 
35 with the respective home provider. 
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Then the authentication server forwards through the 
access network the list of operators to the user. The 
user chooses one of the operators included in the list 
received from the server, according to his local 

5 preferences or based on some pre -configured settings. 
In the case the access provider has a direct roaming 
agreement with the home provider in question, the user 
will be presented with a list made of only one operator 
or the authentication server can decide to directly 

10 forward the authentication request. The user sends back 
to the authentication server in the access network the 
identifier of the operator selected. At this point, the 
authentication server forwards to the provider chosen 
by the user the authentication request, containing the 

15 user' s credentials . 

An alternative possible use of the invention is for 
web-based user authentication. This has the advantage 
of extending the use of this solution for client 
without EAP support. 

20 The procedure is described below. 

The User A requests a service from a wireless 
internet service provider ISP, e.g. by "opening" a web 
browser and by subsequently requesting a URL. The 
access network device intercepts the user 7 s request and 
25 in turn asks the user for his or her credentials, via a 
HTML page. 

The user A submits his or her identity (e.g. in NAI 
format) and password. The credentials are transported 
to the access network device using HTTPS . The access 

30 network device forwards them to the access 
authentication server (AauS) using Diameter 
encapsulation . The access authentication server (AauS) 
in the WISP retrieves the available roaming networks 
for that user. These are identified through the realm 

35 part of the NAI identifier. To accomplish this task, 
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the server initiates a conversation with all the 
servers belonging to the providers to which it is 
connected to, as described previously. 

As a result, the authentication server retrieves 
5 the list of operators that hold a roaming agreement 
with the user's operator. The access authentication 
server (AauS) sends this list of operators to the user. 

In the case the access service provider ASP has a 
direct roaming agreement with the desired home service 
10 provider HSP, the user will be presented with a list 
including only one operator; alternatively the 
authentication server may decide to directly forward 
the authentication request. 

The list is presented to the user with a new HTML 
15 page with IP network selection links. The user chooses 
one of the operators included in the list received from 
the server. 

At this point, the authentication server forwards 
the authentication request, containing the user 

20 credentials, to the provider chosen by the user. The 
home authentication server accepts the user credential, 
checks the user's identity for validation and if 
authentication is successful, orders to the access 
authentication server to give the user service. The 

25 corresponding procedure is depicted in figure 7 . 

The arrangement described is based on the use of a 
Diameter agents. Of course, other * ! triple-A" protocols 
such as Radius may be successfully used, even though 
some of these may not provide for explicit support for 
30 agents, including proxies, redirects and relays. 

Consequently, without prejudice to the underlying 
principle of the invention, the details and the 
embodiments may vary, also significantly, with respect 
to what has been described in the foregoing, just by 
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way of example, without departing from the scope of the 
invention as defined by the annexed claims. 



5 



